jsonrpc: Add async support by jamillambert · Pull Request #558 · rust-bitcoin/corepc

jamillambert · 2026-04-17T14:40:34Z

Pulled out of #505 and polished.

The aim is to add async support without breaking existing sync downstream. This includes keeping the reexports of the current sync Client at the crate root.

satsfy

tACK 5906ce1 - Ran some async tests locally with the new client.

satsfy · 2026-04-17T16:14:42Z

+
+impl BitreqHttpTransport {
+    /// Constructs a new [`BitreqHttpTransport`] with default parameters.
+    pub fn new() -> Self { BitreqHttpTransport::default() }


Just a comment. Should we consider some validation here? So that the user cannot shoot themselves on the foot like:

use jsonrpc::bitreq_http_async::Builder; Builder::new().url("not_a_url").is_ok();

I suppose a validation could happen at new or at fn build(self). No change required, because sync client also does it too. But it's a thought for production.

Raise an issue man, your thoughts are valuable and will be lost if left here!

Worth raising an issue. But not_a_url is a valid URL. I'm not sure what validation would be reasonable.

Thanks I'll put it on the production client's existing issue as an additional consideration.

@satsfy have you spent much time with async code?

@tcharding I don't have enough async experience for a decisive review.

tcharding

ACK 5906ce1 - but I know nothing about async code.

tcharding · 2026-04-18T02:52:40Z

Since we are going to cut a release that includes code I know nothing about (async) I'd love to see PRs up that test everything before we release. Would you consider doing:

A release tracking PR for jsonrpc (bumps version and updates local crates that depend on it).
Rebase the prod RPC client and use the branch/PR created above

Then with green CI on those two PRs we'd have confidence we got things right and we can go ahead and cut the releases.

And if someone with async experience has ten minutes to cast an eye over 5906ce1 please that would be very much appreciated.

tcharding · 2026-04-18T02:53:15Z

@satsfy have you spent much time with async code?

apoelstra · 2026-04-18T13:47:31Z

I have a reasonable amount of experience with async. I'll take a look.

apoelstra · 2026-04-18T15:01:26Z

    pub fn builder() -> Builder { Builder::new() }

-    fn request<R>(&self, req: impl serde::Serialize) -> Result<R, Error>
+    /// Returns the timeout in whole seconds, rounding positive sub-second values up to one.


In 5906ce1:

This is fine, but shouldn't it be done in a separate commit and be done for the sync version too?

I added a commit that changes it in the sync client, this is before the copy of the code to async so it then carries across.

apoelstra · 2026-04-18T15:04:00Z

+        &'a self,
+        req: Request<'a>,
+    ) -> BoxFuture<'a, Result<Response, crate::Error>> {
+        Box::pin(async move { Ok(self.request(req).await?) })


In 5906ce1:

This mess can be replaced with Box::pin(self.request(req))

Much better, thanks.

apoelstra · 2026-04-18T15:04:15Z

+        &'a self,
+        reqs: &'a [Request<'a>],
+    ) -> BoxFuture<'a, Result<Vec<Response>, crate::Error>> {
+        Box::pin(async move { Ok(self.request(reqs).await?) })


In 5906ce1:

...and this one with Box::pin(self.request(reqs))

apoelstra · 2026-04-18T15:08:54Z

-        fn send_request(&self, _: Request) -> Result<Response, Error> { Err(Error::NonceMismatch) }
-        fn send_batch(&self, _: &[Request]) -> Result<Vec<Response>, Error> { Ok(vec![]) }
+        fn send_request<'a>(&'a self, _: Request<'a>) -> BoxFuture<'a, Result<Response, Error>> {
+            Box::pin(async { Err(Error::NonceMismatch) })


In 5906ce1:

This is just a style thing but you can write Box::pin(futures::err(Error::NonceMismatch)) here. It might even compile faster or more efficiently.

apoelstra · 2026-04-18T15:09:14Z

+            &'a self,
+            _: &'a [Request<'a>],
+        ) -> BoxFuture<'a, Result<Vec<Response>, Error>> {
+            Box::pin(async { Ok(vec![]) })


In 5906ce1:

Similarly, futures::ok(vec![])

apoelstra · 2026-04-18T15:11:32Z

-    pub fn send_request(&self, request: Request) -> Result<Response, Error> {
-        self.transport.send_request(request)
+    pub async fn send_request(&self, request: Request<'_>) -> Result<Response, Error> {
+        self.transport.send_request(request).await


In 5906ce1:

It might not be worth the abstraction leak, but you can change this method to return a BoxFuture and then you don't need async or await (and the resulting code will be smaller and faster to compile since it saves you a dummy state machine).

Changed to return a BoxFuture.

Thanks for the review it was very helpful.

Timeouts must be whole seconds for some HTTP clients like bitreq. Round timeouts to whole seconds to avoid issues with these clients.

Code copy only to make it easier in the next patch to see what the changes are for async.

Remove code related to fuzzing from the new async files. Fuzzing of the async client can be added back later if needed.

In preparation for adding another async client change the Debug impl to refer to the local sync Client so that there is no conflict when adding the second async Client struct.

Update the lockfiles because of the new dev dependency on futures.

jamillambert · 2026-04-20T19:57:52Z

Made all of the suggested changes.

apoelstra · 2026-04-21T00:42:06Z

utACK 0aa7803

jamillambert requested a review from tcharding April 17, 2026 14:40

jamillambert requested a review from apoelstra as a code owner April 17, 2026 14:40

github-actions Bot added the C-jsonrpc label Apr 17, 2026

satsfy approved these changes Apr 17, 2026

View reviewed changes

tcharding approved these changes Apr 18, 2026

View reviewed changes

apoelstra reviewed Apr 18, 2026

View reviewed changes

jamillambert added 4 commits April 20, 2026 20:44

Round timeouts to whole seconds

c16f4b5

Timeouts must be whole seconds for some HTTP clients like bitreq. Round timeouts to whole seconds to avoid issues with these clients.

Copy jsonrpc client and bitreq_http for async.

e62b044

Code copy only to make it easier in the next patch to see what the changes are for async.

Remove fuzz related sections

7d556f9

Remove code related to fuzzing from the new async files. Fuzzing of the async client can be added back later if needed.

Change Debug impl to local Client

7302ebd

In preparation for adding another async client change the Debug impl to refer to the local sync Client so that there is no conflict when adding the second async Client struct.

jamillambert force-pushed the 0417-jsonrpc-async branch 2 times, most recently from 3d47015 to 559e8e3 Compare April 20, 2026 19:51

Add async support to jsonrpc

0aa7803

Update the lockfiles because of the new dev dependency on futures.

jamillambert force-pushed the 0417-jsonrpc-async branch from 559e8e3 to 0aa7803 Compare April 20, 2026 19:57

Conversation

jamillambert commented Apr 17, 2026

Uh oh!

satsfy left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

satsfy Apr 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tcharding left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tcharding commented Apr 18, 2026

Uh oh!

tcharding commented Apr 18, 2026

Uh oh!

apoelstra commented Apr 18, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jamillambert commented Apr 20, 2026

Uh oh!

apoelstra commented Apr 21, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

satsfy left a comment •

edited

Loading

satsfy Apr 18, 2026 •

edited

Loading

tcharding left a comment •

edited

Loading